sds: additional support for symlink-based key rotation.#13721
sds: additional support for symlink-based key rotation.#13721htuch merged 16 commits intoenvoyproxy:masterfrom
Conversation
tsaarni
left a comment
There was a problem hiding this comment.
Regardless of working with only a subset of all DataSource use cases, I like this API.
This will work nicely with Kubernetes symlink swap as well, by leaving subdirectory optional 👍
mattklein123
left a comment
There was a problem hiding this comment.
At a high level LGTM with a few comments.
|
I've updated the API to avoid modifying |
|
This now uses hash-based comparison of files after reading twice and validated consistency. This is similar to what gRPC is doing. |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks agreed this seems like a better direction. Flushing out a few API questions/comments.
/wait
|
PTAL, if this makes sense now in terms of API and hash-based comparison implementation then I can fill in the missing tests/docs and move this out of draft. |
mattklein123
left a comment
There was a problem hiding this comment.
From an API perspective this LGTM with one question. LMK when ready for review and I can take a look.
/wait
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
…. Fix format. Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
mattklein123
left a comment
There was a problem hiding this comment.
LGTM with some API comments, thank you!
/wait
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
|
@mattklein123 to deal with failure scenarios I had to add some stats, which then forced me to fix SDS stats more generally, since they were broken before (they all ended up anonymously in the root namespace). PTAL and LMK if there's anything else needed around stats here. |
mattklein123
left a comment
There was a problem hiding this comment.
Thanks LGTM with small questions.
/wait-any
| // If specified, updates of a file-based *trusted_ca* source will be triggered | ||
| // by this watch. This allows explicit control over the path watched, by | ||
| // default the parent directory of the filesystem path in *trusted_ca* is | ||
| // watched if this field is not specified. This only applies when a | ||
| // *CertificateValidationContext* is delivered by SDS with references to | ||
| // filesystem paths. | ||
| config.core.v3.WatchedDirectory watched_directory = 11; |
There was a problem hiding this comment.
I still don't understand how this does anything if there is only a single file above? What's the utility?
There was a problem hiding this comment.
Let's say you have a trusted CA files /foo/bar/baz/ca.pem. By default, envoy watches /foo/bar/baz. If you want to reload when baz is atomically moved, you need to set the watch on /foo/bar. This is what this field allows.
There was a problem hiding this comment.
OK I think having a concrete example might help for this stuff (or ref link back to the docs where you have the example) as it was pretty hard for me to understand the difference.
mattklein123
left a comment
There was a problem hiding this comment.
LGTM. Feel free to do any doc updates as a follow up.
|
Sure, will merge as some folks are depending on this, but I'll take an AI to do the docs followups next week. Thanks. |
Some followup docs tweaks to envoyproxy#13721. Signed-off-by: Harvey Tuch <htuch@google.com>
Some followup docs tweaks to #13721. Signed-off-by: Harvey Tuch <htuch@google.com>
Some followup docs tweaks to envoyproxy#13721. Signed-off-by: Harvey Tuch <htuch@google.com>
…3721) There are a few limitations in our existing support for symlink-based key rotation: We don't atomically resolve symlinks, so a single snapshot might have inconsistent symlink resolutions for different watched files. Watches are on parent directories, e.g. for /foo/bar/baz on /foo/bar, which doesn't support common key rotation schemes were /foo/new/baz is rotated via a mv -Tf /foo/new /foo/bar. The solution is to provide a structured WatchedDirectory for Secrets to opt into when monitoring DataSources. SDS will used WatchedDirectory to setup the inotify watch instead of the DataSource path. On update, it will read key/cert twice, verifying file content hash consistency. Risk level: Low (opt-in feature) Testing: Unit and integration tests added. Fixes envoyproxy#13663 Fixes envoyproxy#10979 Fixes envoyproxy#13370 Signed-off-by: Harvey Tuch <htuch@google.com> Signed-off-by: Qin Qin <qqin@google.com>
Some followup docs tweaks to envoyproxy#13721. Signed-off-by: Harvey Tuch <htuch@google.com> Signed-off-by: Qin Qin <qqin@google.com>
There are a few limitations in our existing support for symlink-based
key rotation:
inconsistent symlink resolutions for different watched files.
which doesn't support common key rotation schemes were /foo/new/baz
is rotated via a mv -Tf /foo/new /foo/bar.
The solution is to provide a structured WatchedDirectory for Secrets to
opt into when monitoring DataSources. SDS will used WatchedDirectory
to setup the inotify watch instead of the DataSource path. On update, it will
read key/cert twice, verifying file content hash consistency.
Risk level: Low (opt-in feature)
Testing: Unit and integration tests added.
Fixes #13663
Fixes #10979
Fixes #13370
Signed-off-by: Harvey Tuch htuch@google.com